The SMS service provides means to transfer messages between a wireless terminal and a remote short message entity via a service center. In 3GPP, the technical realization of the Short Message Service is described in the technical specification 3GPPTS23.040, version 9.1.0, Release 9, published in September 2009, while support of the point-to-point Short Message Service on the mobile radio interface is described in the technical specification 3GPPTS24.011, version 9.0.1, Release 9, published in February 2010.
The directions in which the short messages are sent are referred to as “MO” for Mobile Originating and “MT” for Mobile Terminated.
The SMS service was originally designed for human-operated wireless terminals. Nowadays, it is considered for the development of Machine-Type Communication (MTC), which is a form of data communication involving one or more entities that do not need human interaction. MTC is a Release-10 work item in 3GPP. Related service requirements are given in the technical specification 3GPP TS 22.368, version 1.0.0, published in August 2009. The study on the MTC architecture is the topic of the technical report 3GPPTR23.888, version 0.2.0, published in January 2010. A proposal under study in 3GPPTR23.888 is the use of SMS over Non-Access Stratum (NAS) signaling for transmission of low-volume data.
FIG. 1, copied from 3GPPTS23.040, shows the overall SMS architecture in the universal mobile telecommunication system (UMTS), providing a means for conveyance of short messages between the mobile station (MS) 10 and the SMS Service Centre (SMS-SC) 20. The short messages are carried inside the control plane of the UMTS circuit-switched domain, i.e. via the mobile switching center (MSC), or of the UMTS packet-switched domain, i.e. via the serving GPRS support node (SGSN). The MSC/SGSN 11 cooperates via a reference point 5 with the MS, via a reference point 4 with the visitor location register (VLR) 12 for mobility management, and via a reference point 3 with (i) an SMS-interworking MSC (SMS-IWMSC) 13 for MO messages and (ii) an SMS-Gateway MSC (SMS-GMSC) for MT messages. The SMS-GMSC 15 cooperates with the home location register (HLR) via a reference point 2 to help locating roaming users. For the MT case, the messages may transit via an SMS router 14 having the reference point 3 with the MSC/SGSN 11 on the one hand and with the SMS-GMSC 15 on the other hand. If it is not present, the reference point 3 extends from the SMS-GMSC 15 directly to the MSC/SGSN 11. The reference point 1 is standardized for communication between the SMS-SC 20 and the SMS-IWMSC 13 or SMS-GMSC 15.
The UMTS uses a so-called UMTS terrestrial radio access network (UTRAN) for the radio part of the communication with the MS (also called user equipment, UE). The radio interface is called Uu. The UTRAN has base stations called “node B” distributed over the coverage area of the cellular network and radio network controllers (RNC) interfaced with the MSC/SGSN 11 through an interface called Iu and each controlling a plurality of nodes B. Alternatively, the radio access network can be a GSM-EDGE radio access network (GERAN) with base stations having a radio interface Um with the MSs, and controlled by base station controllers (BSC) connected to the MSC through an interface called A for the circuit-switched (CS) domain and to the SGSN through an interface called Gb for the packet-switched (PS) domain.
The Evolved Packet System (EPS) is a successor of UMTS, developed by 3GPP in the context of the long-term evolution (LTE). It uses an evolved UTRAN (E-UTRAN) for radio access over and LTE-Uu interface. When using the E-UTRAN access, SMS can be delivered via the CS domain (reference point 3) and then via the so-called SGs reference point, connecting the MSC to the mobility management entity (MME), as depicted in FIG. 2, taken from the technical specification 3GPP TS 23.272, version 9.2.0, published in December 2009. The MME 21 is an entity of the evolved packet core (EPC) which communicates with the E-UTRAN through an interface called S1-MME. The MSC entity used for SMS delivery in CS fallback mode in the EPS context is referred to as MSC server 11A. If UTRAN and/or GERAN access is available in an EPS network, the MSC/SGSN node 11 shown in FIG. 1 can be considered as being split between two nodes, the MSC server 11A for the CS domain and the SGSN 11B for the PS domain.
FIG. 2 summarizes available options for the delivery of SMS in a 3GPP network. Corresponding hierarchical models showing the relevant protocol layers in the MS 10 and the peer core network entity are shown in FIGS. 3-6 taken from 3GPPTS24.011, where the following abbreviations are used:                SM-AL Short Message Application Layer;        SM-TL Short Message Transfer Layer;        SM-RL Short Message Relay Layer;        SM-RP Short Message Relay Protocol;        SMR Short Message Relay (entity);        CM-sublayer Connection Management sublayer;        SM-CP Short Message Control Protocol;        SMC Short Message Control (entity);        MM-sublayer Mobility Management sublayer;        GMM-sublayer GPRS Mobility Management sublayer;        RR-sublayer Radio Resource Management sublayer;        LLC-sublayer Logical Link Control sublayer;        GRR-sublayer GPRS Radio Resource sublayer in GSM;        EMM-sublayer EPS Mobility Management sublayer.        
FIG. 3 shows the layer structure of the MSC 11A and the MS 10 for circuit-switched SMS service, the reference point 5 being conveyed through the Uu and Iu-cs interfaces (UTRAN case) or through the Um and A interfaces (GERAN case).
FIG. 4 shows the layer structure of the SGSN 11B and the MS 10 for the SMS service in Gb mode, the reference point 5 being conveyed through the Um and Gb interfaces (GERAN case).
FIG. 5 shows the layer structure of the SGSN 11B and the MS 10 for the SMS service in Iu mode, the reference point 5 being conveyed through the Uu and Iu-ps interfaces (UTRAN case).
FIG. 6 shows the layer structure of the MSC server 11A and the MS 10 for the SMS service in S1 mode, the reference point 5 being conveyed through the LTE-Uu, S1-MME and SGs interfaces (E-UTRAN case). The protocol stack on the MME is not shown.
In each of these scenarios, the MS 10 has a short message relay (SMR) entity 30 on top of an short message control (SMC) entity 31, and a node of the core network (the MSC/MSC server 11A or the SGSN 11B) has corresponding SMR and SMC entities 32, 33. An MS 10 may have two SMR entities and two SMC entities to be able to simultaneously receive MT messages and send MO messages. The peer protocol between two SMC entities is denoted SM-CP, while the peer protocol and between two SMR entities is denoted SM-RP.
The SMR entity using the Short Message Relay Protocol (SM-RP) provides to the Short Message Transport Layer (SM-TL) the service of delivering SMS data in acknowledged mode. The SMS data are sent in relay protocol data (RP_DATA) in suitable SM-RP messages, and the sending SMR entity expects the peer SMR entity to return relay protocol acknowledgment information (RP_ACK).
The acknowledgment information RP_ACK is generated and sent by the peer SMR entity if and when a response is received from the higher layers to which the SMS data were relayed. In the MT case, the higher layer protocol instances receiving the SMS data are also located in the MS, so usually the response is rather quickly received by the SMR entity. In the MO case, the SMS data are intended for the remote SMS-SC 20 and the response acknowledging reception may take longer. The SM-RL procedures provide various behaviors of the SMR entity on the transmitting side if the RP_ACK is not received before expiry of a timer which is typically of the order of a few tens of seconds in the MO case (MS side), or if an error indication is received from the underlying connection management sublayer.
The SMC entity using the Short Message Control Protocol (SM-CP) provides the service of transmitting in acknowledged mode protocol data units from the relay layer (RPDU). An RPDU can consist of RP_DATA, RP_ACK, or other kinds of data units from the SM-RL. The RPDUs are sent in control protocol data (CP_DATA) and the sending SMC entity expects the peer SMC entity to return control protocol acknowledgment information (CP_ACK). The CM-sublayer procedures require retransmission of the RPDU if the CP_ACK is not received before expiry of a timer which is typically of the order of one or a few seconds. A maximum number of such retransmissions (1, 2 or 3) can be performed, and if the CP_ACK is still missing, an error indication is passed to the SM-RL layer.
The message transfers in the SMS-RL and the CM sublayer for SMS delivery are illustrated in FIG. 7 in the MO case and in FIG. 8 for the MT case. Here, the reference sign 100 designates the core network unit which includes the SMR and SMC entities 32, 33 corresponding to those present in the MS 10. This core network unit 100 may be the MSC or MSC server 11A or the SGSN 11B depending on the network architecture.
Not shown in FIGS. 7 and 8 for simplicity is the signaling between the CM-sublayer and the underlying mobility management (MM) layers providing the wireless connection with the MS 10. Generally, the network side decides when to release that connection and instructs the MM layer accordingly. In the MT case, this can be done once the SMR entity 32 in the network unit 100 receives the RP_ACK confirming that the SMS data transfer was successfully completed. In the MO case, the network unit 100 must wait for reception of the final CP_ACK by the SMC entity 33, i.e. the CP_ACK confirming reception of the CP_DATA that carried the RP_ACK. If the SMS are transported in the EPS, the MME 21 handles the connection and the MSC server 11A informs it when connection establishment or release is needed using SGs procedures.
It can happen that an entity has a series of short messages to send. In this case, it is generally useful to maintain the connection between the network unit 100 and the MS 10 in between individual message transfers. The short messages are then concatenated without release of the connection. For MT transfers, this is easily done under control of the network unit 100 which controls release of the connection. If several MT short messages follow each other, the network unit 100 can keep the connection alive after receipt of the RP_ACK relating to SMS data which are not the last ones of the series and use that connection again for transmission of further SMS data. If a final CP_ACK is not received by the SMC entity 31 on the MS side, e.g. due to transmission errors or handover, there can be some retransmissions of the CP_DATA carrying the RP_ACK. In the meantime, if the SMC entity 31 on the MS side receives further CP_DATA with a different transaction identifier, i.e. carrying new RP_DATA as RPDU, it interprets that reception as an implicit reception of the missing final CP_ACK.
For concatenated MO short message transfers, the network unit 100 does not know whether or not the MS has more messages to transfer. If the MS chooses to use the same connection for transferring further SMS data of a series, it must refrain from acknowledging the CP_DATA that carried the RP_ACK by means of the final CP_ACK, in order to avoid undesired release of the connection by the network. Instead, the SMC entity 31 on the MS side can transmit CP_DATA for the next RPDU containing new RP_DATA. Here too, reception of such CP_DATA with a different transaction identifier and carrying an RPDU is interpreted by the peer SMC entity 33 on the network side as the implicit reception of the awaited final CP_ACK. A final CP_ACK is eventually returned by the MS 10 when it has no more SMS data to transfer, so the peer SMC entity 33 in the network can trigger release of the connection.
FIG. 9 illustrates the transfer of a series of three concatenated MO short messages. It is seen that the SMC entity 31 on the MS side responds to CP_DATA 40 carrying an RP_ACK by returning a final CP_ACK 41 only when the whole series of concatenated messages has been successfully transferred. Before that, downlink CP_DATA 42 (carrying an RP_ACK) is not acknowledged by the SMC entity 31 which simply forwards the RP_ACK to the SMR entity 30. After reception of the RP_ACK, the SMR entity 30 can provide new RP_DATA, and the SMC entity 31 sends CP_DATA 43 to the network side, containing the new RP_DATA. The peer SMC entity 33 then interprets reception of this CP_DATA 43 as acknowledging the previously sent CP_DATA 42.